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Abstract 


The Dynamic Host Configuration Protocol (DHCP) provides a framework 
for passing configuration information to hosts on a Transmission 
Control Protocol/Internet Protocol (TCP/IP) network. Configuration 
parameters and other control information are carried in tagged data 
items that are stored in the ’options’ field of the DHCP message. 
The data items themselves are also called "options". 


DHCP protocol messages are identified by the ’DHCP Message Type’ 
option (option code 51). Each message type is defined by the data 
value carried in the ’DHCP Message Type’ option. 


New DHCP options and message types may be defined after the 
publication of the DHCP specification to accommodate requirements for 
conveyance of new configuration parameters or to accommodate new 
protocol semantics. This document describes the procedure for 
defining new DHCP options and message types. 


1. Introduction 


The Dynamic Host Configuration Protocol (DHCP) [1] provides a 
framework for passing configuration information to hosts on a TCP/IP 
network. Configuration parameters and other control information are 
carried in tagged data items that are stored in the ’options’ field 
of the DHCP message. The data items themselves are also called 
"options" [2]. 
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DHCP protocol messages are identified by the ’DHCP Message Type’ 
option (option code 51). Each message type is defined by the data 
value carried in the ’DHCP Message Type’ option. 


This document describes the procedure for defining new DHCP options 
and message types. The procedure will guarantee that: 


* allocation of new option numbers and message type numbers is 
coordinated from a single authority, 

* new options and message types are reviewed for technical 
correctness and appropriateness, and 

* documentation for new options and message types is complete and 
published. 


As indicated in, "Guidelines for Writing an IANA Considerations 
Section in RFCs", (see references), IANA acts as a central authority 
for assignment of numbers such as DHCP option and message type codes. 
The new procedure outlined in this document will provide guidance to 
IANA in the assignment of new option and message type codes. 


This document updates and replaces RFC 2489. 
2. Overview and background 


This document specifies procedures for defining new option codes and 
message types. 


2.1 New DHCP option codes 


The procedure described in this document modifies and clarifies the 
procedure for defining new options in RFC 2131 [2]. The primary 
modification is to the time at which a new DHCP option is assigned an 
option number. In the procedure described in this document, the 
option number is not assigned until specification for the option is 
about to be published as an RFC. 


Since the publication of RFC 2132, the option number space for 
publicly defined DHCP options (1-127) has almost been exhausted. 
Many of the defined option numbers have not been followed up with 
Internet Drafts submitted to the DHC WG. There has been a lack of 
specific guidance to IANA from the DHC WG as to the assignment of 
DHCP option numbers. 


The procedure as specified in RFC 2132 does not clearly state that 
new options are to be reviewed individually for technical 
correctness, appropriateness and complete documentation. RFC 2132 
also does not require that new options are to be submitted to the 
IESG for review, and that the author of the option specification is 
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responsible for bringing new options to the attention of the IESG. 
Finally, RFC 2132 does not make clear that newly defined options are 
not to be incorporated into products, included in other 
specifications or otherwise used until the specification for the 
option is published as an RFC. 


In the future, new DHCP option codes will be assigned by IETF 
consensus. New DHCP options will be documented in RFCs approved by 
the IESG, and the codes for those options will be assigned at the 
time the relevant RFCs are published. Typically, the IESG will seek 
input on prospective assignments from appropriate sources (e.g., a 
relevant Working Group if one exists). Groups of related options may 
be combined into a single specification and reviewed as a set by the 
IESG. Prior to assignment of an option code, it is not appropriate 
to incorporate new options into products, include the specification 
in other documents or otherwise make use of the new options. 


The DHCP option number space (1-254) is split into two parts. The 
site-specific option codes [2] (128-254) are defined as "Private Use" 
and require no review by the DHC WG. Site-specific options codes 
(128-254) MUST NOT be defined for use by any publicly distributed 
DHCP server, client or relay agent implementations. These option 
codes are explicitly reserved for private definition and use within a 
site or an organization. 


The public option codes (0-127, 255) are defined as "Specification 
Required" and new options must be reviewed prior to assignment of an 
option number by IANA. The details of the review process are given 
in the following section of this document. 


2.2 New DHCP message types 


RFC 2131 does not specify any mechanism for defining new DHCP message 
types. In the future, new DHCP message types will be documented in 
RFCs approved by the IESG, and the codes for these new message types 
will be assigned at the time the relevant RFCs are published. 


Typically, the IESG will seek input on new message types from 
appropriate sources (e.g., a relevant Working Group if one exists). 
Prior to assignment of a message type code, it is not appropriate to 
incorporate new message types into products, include the 
specification in other documents or otherwise make use of the new 
message types. 
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3. Procedure 


The author of a new DHCP option or message type will follow these 
steps to obtain approval for the option and publication of the 
specification of the option as an RFC: 


li; 


2. 


The author devises the new option or message type. 


The author documents the new option or message type, leaving the 
option code or message type code as "To Be Determined" (TBD), as 
an Internet Draft. 


The requirement that the new option or message type be documented 
as an Internet Draft is a matter of expediency. In theory, the 
new option or message type could be documented on the back of an 
envelope for submission; as a practical matter, the specification 
will eventually become an Internet Draft as part of the review 
process. 


The author submits the Internet Draft for review by the IESG. 
Preferably, the author will submit the Internet Draft to the DHC 
Working Group, but the author may choose to submit the Internet 
Draft directly to the IESG. 


Note that simply publishing the new option or message type as an 
Internet Draft does not automatically bring the option to the 
attention of the IESG. The author of the new option or message 
type must explicitly forward a request for action on the new 
option to the DHC WG or the IESG. 


The specification of the new option or message type is reviewed by 
the IESG. The specification is reviewed by the DHC WG (if it 
exists) or by the IETF. If the option or message type is accepted 
for inclusion in the DHCP specification, the specification of the 
option or message type is published as an RFC. It may be 
published as either a standards-track or a non-standards-track 
RFC. 


At the time of publication as an RFC, IANA assigns a DHCP option 
code or message type code to the new option or message type. 
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5. Changes from RFC 2489 


This document extends the procedures for defining new DHCP options 
specified in RFC 2489 [5] to include the definition of new DHCP 
message types. The language reserving site-specific option codes has 
been strengthened to emphasize the requirement that site-specific 
option codes must not be encoded in publicly distributed DHCP 
implementations. 


6. Security Considerations 


Information that creates or updates an option code or message type 
code assignment needs to be authenticated. 


An analysis of security issues is required for all newly defined DHCP 
options or message types. The description of security issues in the 
specification of new options or message types must be as accurate as 
possible. The specification for a new option or message type may 
reference the "Security Considerations" section in the DHCP 
specification [1]; e.g., (from "NetWare/IP Domain Name and 
Information" [3]): 


DHCP currently provides no authentication or security mechanisms. 
Potential exposures to attack are discussed in section 7 of the 
DHCP protocol specification [RFC 2131]. 


7. IANA Considerations 


RFC 2132 and RFC 2489 provided guidance to the IANA on the procedure 
it should follow when assigning option numbers for new DHCP options 
or message types. This document updates and replaces those 
instructions. In particular, IANA is requested to assign DHCP option 
codes or message type codes only for options or message types that 
have been approved for publication as RFCs; i.e., documents that have 
been approved through "IETF consensus" as defined in RFC 2434 [4]. 
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9. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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